Radio sensor coverage estimation for wireless network assurance

ABSTRACT

An apparatus, computer program product, and method relating to radio sensor coverage estimation for wireless network assurance. A network controller estimates a network sensor coverage level for candidate access points (APs), based on potential use of the candidate APs as network sensors to measure at least one key performance indicator (KPI). The controller determines a subset of the candidate APs, based on evaluating candidate APs for suitability as network sensors. The controller estimates a second network sensor coverage level for the subset of candidate APs, based on potential use of the subset of candidate APs as network sensors. The controller determines that the second network sensor coverage level is within a pre-defined threshold of the first network sensor coverage level, and provisions a radio in each AP in the subset of candidate APs as a network sensor to measure at least one KPI.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of co-pending U.S. patent applicationSer. No. 16/741,539, filed Jan. 13, 2020, which will issue on Jul. 20,2021 as U.S. Pat. No. 11,071,001 which is a continuation of U.S. patentapplication Ser. No. 15/875,650, filed Jan. 19, 2018, which issued onJan. 14, 2020 as U.S. Pat. No. 10,536,871 and claims benefit of U.S.provisional patent application Ser. No. 62/527,810, filed Jun. 30, 2017.The aforementioned related patent application is herein incorporated byreference in its entirety.

BACKGROUND

High-density wireless deployments have become more common in recentyears. With the proliferation of these deployments, monitoring networkperformance has become increasingly important to, for example, avoidnetwork problems, ensure a desired performance level, and ensurecompliance with service level agreements. In wireless networks systemmetrics and performance can vary significantly over time. Therefore, itis important to determine network health and performance on an ongoingbasis.

This can be done using network sensors to measure network performance.For example, network technicians can visit a client site with dedicatedsensors, and use these sensors to monitor and troubleshoot the network.But this is expensive, inefficient, and inflexible, requiringtechnicians to visit client sites in person and to set up dedicatedsensors.

SUMMARY

An embodiment described herein is a network controller that includes aprocessor and a memory containing a program that, when executed on theprocessor, performs an operation. The operation includes estimating afirst network sensor coverage level for a plurality of candidate accesspoints (APs), based on potential use of the plurality of candidate APsas network sensors to measure at least one key performance indicator(KPI). The operation further includes determining a subset of theplurality of candidate APs, based on evaluating the plurality ofcandidate APs for suitability as network sensors. The operation furtherincludes estimating a second network sensor coverage level for thesubset of the plurality of candidate APs, based on potential use of thesubset of the plurality of candidate APs as network sensors. Theoperation further includes determining that the second network sensorcoverage level is within a pre-defined threshold of the first networksensor coverage level. The operation further includes provisioning aradio in each AP in the subset of the plurality of candidate APs as anetwork sensor to measure at least one KPI.

A further embodiment described herein is a computer program product thatincludes a non-transitory computer-readable storage medium havingcomputer readable program code embodied on it, the computer readableprogram code executable by one or more computer processors to perform anoperation. The operation includes estimating a first network sensorcoverage level for a plurality of candidate APs, based on potential useof the plurality of candidate APs as network sensors to measure at leastone KPI. The operation further includes determining a subset of theplurality of candidate APs, based on evaluating the plurality ofcandidate APs for suitability as network sensors. The operation furtherincludes estimating a second network sensor coverage level for thesubset of the plurality of candidate APs, based on potential use of thesubset of the plurality of candidate APs as network sensors. Theoperation further includes determining that the second network sensorcoverage level is within a pre-defined threshold of the first networksensor coverage level. The operation further includes provisioning aradio in each AP in the subset of the plurality of candidate APs as anetwork sensor to measure at least one KPI.

A further embodiment described herein is a method. The method includesestimating a first network sensor coverage level for a plurality ofcandidate APs, based on potential use of the plurality of candidate APsas network sensors to measure at least one key performance indicator(KPI). The method further includes determining a subset of the pluralityof candidate APs, based on evaluating the plurality of candidate APs forsuitability as network sensors. The method further includes estimating asecond network sensor coverage level for the subset of the plurality ofcandidate APs, based on potential use of the subset of the plurality ofcandidate APs as network sensors. The method further includesdetermining that the second network sensor coverage level is within apre-defined threshold of the first network sensor coverage level. Themethod further includes provisioning a radio in each AP in the subset ofthe plurality of candidate APs as a network sensor to measure at leastone KPI

BRIEF DESCRIPTION OF THE DRAWINGS

So that the manner in which the above-recited features of the presentdisclosure can be understood in detail, a more particular description ofthe disclosure, briefly summarized above, may be had by reference toembodiments, some of which are illustrated in the appended drawings. Itis to be noted, however, that the appended drawings illustrate onlytypical embodiments of this disclosure and are therefore not to beconsidered limiting of its scope, for the disclosure may admit to otherequally effective embodiments.

FIG. 1 illustrates a network controller controlling multiple AccessPoints (APs) in a network, according an embodiment.

FIG. 2 illustrates a network controller, according to an embodiment.

FIG. 3 illustrates a neighborhood including multiple APs, according toan embodiment.

FIG. 4 is a flowchart for evaluating radio sensor coverage, according toan embodiment.

FIG. 5 is a flowchart for choosing APs and selecting allowed frequencieswhen evaluating radio sensor coverage, according to an embodiment.

FIG. 6 is a flowchart for evaluating neighboring nodes for an AP whenevaluating radio sensor coverage, according to an embodiment.

FIG. 7 is a flowchart for optimized pruning when evaluating radio sensorcoverage, according to an embodiment.

FIGS. 8A-8D illustrate an example of evaluating radio sensor coveragefor the neighborhood illustrated in FIG. 3, according to an embodiment.

To facilitate understanding, identical reference numerals have beenused, where possible, to designate identical elements that are common tothe figures. It is contemplated that elements disclosed in oneembodiment may be beneficially utilized on other embodiments withoutspecific recitation.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Instead of using on-site technicians and dedicated hardware, it ispossible to determine the network health and performance of a wirelessnetwork using the existing Access Points (APs) in the wireless networkas wireless sensors for other APs and clients. These sensors can be usedto measure key performance indicators (KPI), continuously or atintervals, and can report any degradation in the key performanceindicators. Key performance indicators may include: wireless clienttroubleshooting, radio performance, client throughput estimation, radiosignal coverage, network authentication issues, coverage holes, andother indicators. Such degradation can be due to numerous factorsincluding, for example, wireless interference.

When an AP is used as a sensor, however, the radio being used forsensing cannot be used to service clients. One solution is to setupdedicated APs to use as permanent sensors. This allows consistentmonitoring of the network, but using a dedicated AP can be expensive,and many wireless deployments do not have spare APs available to serveas permanent sensors.

Another solution is to use as sensors APs that include a radio that istemporarily redundant and not currently necessary to service clients. Todo this, one can identify available APs, and then select a subset of theavailable APs to use as sensors. These APs can then temporarily serve assensors, and can measure the desired key performance indicators. In oneembodiment, available APs can be identified through Flexible RadioAssignment (FRA) functionality, or other suitable methods. Algorithmscan then be used to select which of the available APs to use as sensorsin order to optimize the sensor coverage and functionality without tyingup APs unnecessarily and without harming client service.

FIG. 1 illustrates a network controller controlling a plurality of APsin a network, according to one embodiment herein. In FIG. 1, the networkcontroller 101 controls a plurality of APs from AP1 to AP5. In oneembodiment, each AP includes two radios where the first radio is adedicated 5 GHz radio that transmits signals in the 5 GHz frequency bandand the second radio is a XOR radio that can dynamically switch betweenthe 2.4 GHz and 5 GHz frequency bands. That is, the second radio cantransmit signals in either the 2.4 GHz frequency band or the 5 GHzfrequency band. The two radios in an AP can be active simultaneously onthe same frequency band or on different frequency bands. For example,the XOR radio and the dedicated 5 GHz radio in an AP can simultaneouslytransmit signals in the 5 GHz frequency band by using different channelsof the 5 GHz frequency band. In one embodiment, the network controller101 can be an AP, e.g., a master AP that can control other APs. Inanother embodiment, the network controller 101 can be a separatecomputing device. In another embodiment, the network controller 101 canbe a device in a cloud computing environment.

In one embodiment, the APs can offer various services based on thenetwork deployment and client density. For example, the AP1-AP5 have twooperation modes, i.e., a local working mode and a non-client servingrole. The operation modes apply to both radios of an AP. Also, theradios in AP1-AP5 have two radio roles, i.e., a dedicated radio role andan XOR radio role. In one embodiment, when operating in the localworking mode, the dedicated 5 GHz radio transmits signals in the 5 GHzfrequency band and the XOR radio transmits signals in either the 2.4 GHzfrequency band or the 5 GHz frequency band. In the non-client servingrole, however, the dedicated 5 GHz radio and the XOR radio do nottransmit signals in either the 5 GHz or the 2.4 GHz frequency bands.Also, in one embodiment, in the non-client serving role, the radiosconsume lower power than in the local working mode. In anotherembodiment, in the non-client serving role, the radios are passivemonitors that can receive signals transmitted on the 5 GHz or the 2.4GHz frequency bands but do not transmit signals.

In one embodiment, the network controller 101 determines whether a radioin an AP is redundant. This can be done using Flexible Radio Assignment(FRA) functionality, which is discussed in more detail in U.S. patentapplication Ser. No. 15/475,577. That application's discussion of FRA,and associated network architecture and algorithms, is herebyincorporated by reference.

That is, the network controller 101 determines whether coverage area ofthe radio is already covered sufficiently (fully or almost fully) by atleast one radio in a neighboring AP. For example, if APIs XOR radiotransmits signals using a channel of the 2.4 GHz frequency band and ifAP2 and AP3's XOR radios also transmit signals using the same channel ofthe 2.4 GHz frequency band which cover the same area as APIs XOR radio,then APIs XOR radio is redundant. In this situation, APIs redundant XORradio may cause co-channel interference with AP2 and AP3's XOR radios.

If the network controller 101 determines that a radio in an AP isredundant in a frequency band, the network controller 101 manages theredundant radio to mitigate co-channel interference in the frequencyband, e.g., the network controller 101 prohibits the redundant radiofrom transmitting signals in the frequency band. In one embodiment, thenetwork controller 101 instructs APIs XOR radio to switch to the 5 GHzfrequency band. That is, the network controller 101 switches APIs XORradio to transmit signals in the 5 GHz frequency band, so that APIs XORradio does not transmit signals in the 2.4 GHz frequency band. Thus, theXOR radio of AP1 not only does not cause co-channel interference in the2.4 GHz frequency band but also increases capacity in the 5 GHzfrequency band. In another embodiment, the network controller 101instructs APIs XOR radio to change from the local working mode to thenon-client serving role so that AP1's XOR radio does not transmitsignals in the 2.4 GHz frequency band and does not cause co-channelinterference in that band. In other embodiments, based on the networkdeployment and user preference, the network controller 101 instructsAPIs XOR radio to change from the local working mode to provide otherservices such as acting as a wireless sensor.

FIG. 1 illustrates only one embodiment herein. In other embodiments, thenetwork controller 101 may control a different number of APs. Moreover,the APs may include a different number of radios. For example, the APsmay include a dedicated 5 GHz radio, a dedicated 2.4 GHz radio, and aXOR radio. In other embodiments, the radios of the APs may transmitsignals in frequency bands different from the 5 GHz frequency band andthe 2.4 GHz frequency band, as understood by an ordinary person in theart.

FIG. 2 illustrates the network controller 101, according to oneembodiment herein. The network controller 101 includes a processor 201and a memory 202. The processor 201 may be any computer processorcapable of performing the functions described herein. Although memory202 is shown as a single entity, memory 202 may include one or morememory devices having blocks of memory associated with physicaladdresses, such as random access memory (RAM), read only memory (ROM),flash memory or other types of volatile and/or non-volatile memory.

The memory 202 includes a radio resource management (RRM) component 203.The RRM component 203 provides a system level management of co-channelinterference, radio resources, and other radio transmissioncharacteristics in the network. The RRM component 203 includes corealgorithms for controlling parameters such as transmit power, userallocation, beamforming, data rates, handover criteria, modulationscheme, error coding scheme, etc. The RRM component 203 aims to utilizethe radio-frequency resources and radio network infrastructure in anefficient way.

In one embodiment, the RRM component 203 receives inter-radiomeasurement data reported from the APs controlled by the networkcontroller 101. The inter-radio measurement data may include but is notlimited to the channel frequency between two radios of different APs,transmit power, antenna information and the received signal strengthindicator (RSSI) or path loss between two radios of different APs.

In one embodiment, the RRM component 203 performs the inter-radiomeasurement based on a neighbor discovery protocol (NDP). By using NDP,each radio in each AP sends a broadcast message to all other radios inall other APs on all channels so that all other radios operating ondifferent channels can receive the broadcast message. The broadcastmessage may be a neighbor discovery packet with a predefined packetformat. When a radio in an AP receives the neighbor discovery packet, ituses the neighbor discovery packet to obtain the inter-radio measurementdata, and forwards the neighbor discovery packet and the inter-radiomeasurement data to the RRM component 203. Based on the receivedneighbor discovery packet and the inter-radio measurement data, the RRMcomponent 203 can understand how every radio using a channel hears everyother radio using the same channel and how every AP relates to other APsin the network controlled by the network controller 101.

The RRM component 203 includes a redundancy identification engine (RIE)204. Based on the measurement data received by the RRM component 203,the RIE 204 can identify redundant radios in APs in a frequency band.The RIE 204 includes a density value calculator 205, a radio frequency(RF) constellation calculator 206 and a redundancy determinator 207. Thedensity value calculator 205 identifies candidate APs for redundancydetermination, the RF constellation calculator 206 calculates relativelocations of neighboring APs, and the redundancy determinator 207determines whether a radio in an AP is redundant.

The redundancy determinator 207 includes a coverage peak flatteningsimulator 208 and a multi-point checker 209. The coverage peakflattening simulator 208 models a total coverage area covered by radiosin a plurality of APs and determines whether multiple radios arecovering an overlapping area of the total coverage area. The coveragepeak flattening simulator 208 also predicts an impact to the totalcoverage area if a radio in a selected AP does not transmit signals in afrequency band.

After the coverage peak flattening simulator 208 determines that theimpact to total coverage area is acceptable if the radio in the selectedAP does not transmit signals in a frequency band, the multi-pointchecker 209 further checks whether the radio is contributing to coverageareas of one or more radios in neighboring APs that are alreadydetermined as redundant. For example, if a radio in a neighboring APdoes not transmit signals in the frequency band because the radio in theneighboring AP was previously identified by the RIE 204 as redundant,the multi-point checker 209 checks whether the radio in the selected APis transmitting signals in the original coverage area (the coverage areabefore the redundant radio is prohibited from transmitting signals) ofthe redundant radio in the neighboring AP. If the coverage area of theradio in the selected AP does not overlap with the coverage areas of oneor more radios in neighboring APs that are already determined asredundant, the multi-point checker 209 further ensures that the coveragearea of the radio in the selected AP is sufficiently covered by one ormore radios in neighboring APs that are transmitting signals in thefrequency band. Algorithms implemented by the coverage peak flatteningsimulator 208 and the multi-point checker 209 are discussed in moredetail in U.S. patent application Ser. No. 15/475,577, and are herebyincorporated by reference.

FIG. 3 illustrates a neighborhood including multiple APs, according toone embodiment herein. The dotted lines and arrows between APs representneighbor relationships. For example, AP 3 is a TX neighbor of AP1,meaning at least one of AP1 s radios can reach AP3. This is illustratedwith the dotted line between AP1 and AP3 and the arrow pointing from AP1to AP3. AP3 is also an RX neighbor of AP1, meaning at least one of AP3'sradios can reach AP1. This is illustrated with the arrow pointing fromAP3 to AP1.

As illustrated in FIG. 3, AP1 has four neighbors: AP3, AP5, AP2, andAP4. AP2 has three neighbors: AP5, AP4, and AP6. AP3 has two neighbors:AP1 and AP5; AP4 has two neighbors: AP1 and AP2; and AP5 has threeneighbors, AP3, AP2, and AP1. Each of these are both TX and RXneighbors, as illustrated by the arrows in FIG. 3. The neighborrelationships illustrated in FIG. 3 will be discussed in more detailwith regard to FIGS. 8A-8D.

FIG. 4 is a flowchart for evaluating radio sensor coverage, according toan embodiment. In one embodiment, FIG. 4 relates to a wireless LANnetwork with a number of APs. At step 402, the system is initialized andmaintains three buckets of APs: Available_Sensors, Covered_Neighbors,and Supplementary_List. Covered_Neighbors and Supplementary_List areinitially empty. Available_Sensors is initialized with a list ofcandidate APs. There are various ways to identify the Available_Sensorscandidate APs in a given network. In one embodiment, the system choosesthe radios that have no load/clients (or the smallest load) as theAvailable_Sensors, or radios that are covered by multiple neighbors asthe Available_Sensors, or a combination of both. Alternatively, theAvailable_Sensors can be identified using an FRA algorithm to determineredundant APs in the network as discussed in FIG. 2, above. For example,an FRA algorithm can be used to identify APs that include at least oneradio that is redundant, meaning the radio is not necessary for clientservice. The Available_Sensors bucket can be populated with these APs.

At step 404, the system chooses an AP from the Available_Sensors bucketand evaluates the AP's suitability for use as a network sensor based onvarious sensor-coverage factors. A sensor-coverage factor can be anyfactor used to evaluate the AP's suitability to act as a network sensor.For example, the system can select the allowed frequencies for sensoroperation for the selected AP. The allowed frequencies for sensoroperation are an example of a sensor-coverage factor, as is the basepower range (discussed in more detail with regard to step 506 in FIG.5). The system also gathers information on the selected AP's neighbors,and generates a list of neighbors. This is another example of asensor-coverage factor. Step 404 is discussed in more detail with regardto FIG. 5.

As another example, at step 406, the system evaluates the neighboringnodes or APs for transmit cell size. As part of this process, in oneembodiment, the system can evaluate signal to noise ratio (SNR) for TXneighbors. These are additional examples of sensor-coverage factors.Step 406 is discussed in more detail with regard to FIG. 6.

At step 408, the system checks the bucket of Available_Sensors todetermine whether it has evaluated each of the sensors in this bucket.If not, the system returns to step 404. The system repeats steps 404 and406 until all the APs in the Available_Sensors bucket have beenevaluated.

If all of the APs in the Available_Sensors bucket have been evaluated,the system proceeds to step 410. At step 410, the system estimates thenetwork sensor coverage level. For example, the system can estimate howmuch of the network could be measured if all of the APs in theAvailable_Sensors bucket were used as network sensors. The estimate canbe generated by measuring statistics for each AP per sector, for theoverall network, or for both. A sector can be, for example, a local areathat is relatively isolated from other APs, such as an auditorium or alarge conference room. One example of a measured statistic used ingenerating the estimate is “Network Sensor Coverage,” which comparesnodes under Covered_Neighbors against the total radios in the RF group.Another example of a measured statistic is “Localized RF Sector SensorCoverage,” which measures the number of Covered_Neighbors per site,divided by the radios subscribed to that site. Another example of ameasured statistic is “Radio Sensor Coverage”, which is the measuredCovered_Neighbors per radio divided by the total TX neighbors

At step 412, the system assigns a network sensor covered percentagefactor to the RF domain, the localized RF sectors, or both. For example,the assignment can involve storing heuristics and statisticalmeasurements in a centralized database. The network controller can pushthe heuristics and measurements to group members, which can store theinformation in a database.

At step 414, the system performs optimized pruning, which removesunnecessary sensors from the Available_Sensors bucket. Step 414 isdescribed in more detail with regard to FIG. 7. At step 416, the systemre-estimates the network sensor coverage level after performing theoptimized pruning in step 414. This estimate can be done on a per-sitebasis, on an overall basis, or both. In one embodiment, the systemensures that the per-site sensor coverage, the overall sensor coverage,or both, remain within a pre-defined threshold of 100% or of the valuecomputed in step 410. This pre-defined threshold can be 0, meaning thatthe re-estimated coverage level must be the same as the value computedat step 410, or it can be any suitable threshold value.

FIG. 5 is a flowchart for choosing APs and selecting allowed frequencieswhen evaluating radio sensor coverage, according to an embodiment. FIG.5 provides more detail regarding step 404 of FIG. 4, discussed above. Atstep 502, the system selects a candidate AP from the bucket ofAvailable_Sensors.

At step 504, the system selects the allowed sensor frequencies, shouldthe candidate AP be used as a network sensor. The system starts with alist of available frequencies, and chooses a subset of frequencies basedon PHY constraints. PHY constraints are hardware constraints of theselected radio that can prevent sensor operation. For example, asdiscussed above with regard to FIG. 1, an AP may have two radios, amaster radio operating at 5 GHz and an XOR radio that can selectivelyoperate at either 5 GHz or 2.4 GHz. In one embodiment, the master radiocan be used for client operation, while the XOR radio is used forsensing. But if the wrong frequency is chosen for sensing, the XOR radiocould interfere with the client operation of the master radio. Forexample, the XOR radio may interfere if it uses a frequency that iswithin 100 MHz, from spectrum edge to spectrum edge, of the masterradio. The XOR radio may have a limited set of available 5 GHzfrequencies that avoid this interference.

In another embodiment, either the master or XOR radio can be used forsensing. Either radio, when used for sensing, could interfere withclient operation of a nearby AP if the wrong frequency is chosen. Inthis embodiment the system can choose frequencies that will notinterfere with neighboring APs. In both circumstances, the systemselects the frequencies that are sufficiently isolated from nearbyradios, whether the nearby radio is in the same AP or in a nearby AP.These selected frequencies can be termed White List Frequencies.

Once the system determines the White List Frequencies, it can determinechannel quality for these frequencies. Some channels may have additionalWi-Fi or non-Wi-Fi interference. This interference can limit sensoroperation on that channel. To avoid using a low quality channel, thesystem can determine a Channel Quality Index for each channel, comparethat Channel Quality Index with a CLEAR_CHANNEL_CRITERIA_THRESHOLD(e.g., 25%), and only select channels for which the Channel QualityIndex is above the threshold. In one embodiment, the allowed frequenciesare the frequencies that both meet the PHY constraints and the channelquality threshold.

At step 506, the system establishes a base power range within thefrequencies. When an AP is used as a sensor, the AP operates as awireless client. This means the power level of the AP's sensor radio canbe governed by the target AP for which the sensor AP is acting as aclient, and so the power level of the sensor radio can drop duringoperation. The system, therefore, can determine the lowest power level,across the available power levels and for each frequency, at which thesensor radio can reach the target APs and act as a sensor. In oneembodiment, this is done using the Unlicensed National Information (UNI)bands.

At step 508, the system gathers neighbor information for the sensorcandidate AP. This information comes from both TX and RX neighbors thatsurround the candidate sensor AP. In one embodiment, at step 510 thesystem filters and removes neighboring APs that are not at operating theallowed frequencies of the candidate sensor AP.

FIG. 6 is a flowchart for evaluating neighboring nodes for an AP whenevaluating radio sensor coverage, according to an embodiment. FIG. 6provides more detail regarding step 406 of FIG. 4, discussed above. Atstep 602, the system chooses the next neighbor in the list of TX and RXneighbors for the candidate AP. This list can come from, for example,the gathering of neighbor information at step 508, discussed above.

At step 604, the system evaluates the signal-to-noise ratio (SNR) forthe radio. The SNR can affect the ability of the candidate AP to sensethe neighbor. At step 606 the system checks whether the SNR meets theSensor_Boundary_SNR_Cutoff. This ensures that the SNR is sufficient forthe desired sensing. In one embodiment, the Sensor_Boundary_SNR_Cutoffis a dynamic threshold that varies according to an active client profile(e.g., type of client such as mobile phone, tablet, laptop, etc.), datatype (e.g., voice video, or best effort), and/or test requirements(e.g., a ping-equivalent test or link estimation). TheSensor_Boundary_SNR_Cutoff can be set to a default value (e.g., 35). TheSensor_Boundary_SNR_Cutoff can also be configured by a user. Forexample, the system could provide a user interface with a slider bar,with which the user can configure the cutoff.

If the SNR does not meet the Sensor_Boundary_SNR_Cutoff, the systemreturns to step 602 and evaluates the next neighbor. If the SNR meetsthe Sensor_Boundary_SNR_Cutoff, the system proceeds to step 608. At step608, the system determines whether the neighbor is already present inthe Covered_Neighbors bucket. If the neighbor is not already present inthe bucket, the system proceeds to step 610 and adds the neighbor to theCovered_Neighbors bucket. If the neighbor is already present in theCovered_Neighbors bucket, the system adds the neighbor to theSupplementary_List. The candidate AP can also be stored in theSupplementary_List, so that the relationship from candidate AP->neighboris recorded. Storage in the Supplementary_List indicates that multiplecandidate APs cover the same neighbor and permits the system torepresent multiple APs covering similar RF zones.

At step 614, the system checks whether all suitable neighbors for thecandidate AP have been evaluated. If not, the system returns to step 602and proceeds to evaluate the next neighbor. If so, the system concludesthis portion of the process and proceeds to step 408 in FIG. 4,discussed above.

FIG. 7 is a flowchart for optimized pruning when evaluating radio sensorcoverage, according to an embodiment. FIG. 7 provides more detailregarding step 414 of FIG. 4, discussed above. At step 702, the systemremoves from the Available_Sensors bucket APs which produce zerocoverage or have a zero reachability factor. At step 704, the systemevaluates APs with minimal sensor reachability. For example, when sensorreachability is minimal, the system evaluates whether other candidatesensor APs can reach the Covered_Neighbors of this radio. If othercandidate sensor APs can cover all the neighbors covered by thiscandidate sensor AP, as denoted in the Covered_Neighbors bucket, thiscandidate sensor AP can be removed from the Available_Sensors bucket. Aspart of this process, neighbors may be moved from the Supplementary_Listto the Covered_Neighbors bucket.

At step 706, the system removes APs appearing only in theSupplementary_List. As discussed above, with regard to step 612 in FIG.6, a neighbor appears in the Supplementary_List if the neighbor isalready included in the Covered_Neighbors bucket. An AP that appearsonly in the Supplementary_List is not necessary for full sensorcoverage, because each of the neighbors it covers is already covered byanother candidate sensor AP. This is discussed in more detail withregard to FIGS. 8A-8D.

FIGS. 8A-8D illustrate a partial example of evaluating radio sensorcoverage for the neighborhood illustrated in FIG. 3, according to anembodiment. Assume, for example, that an FRA algorithm identifies AP1,AP2, and AP3 as candidate sensor APs. Following along with FIG. 4, andas shown in FIG. 8A, at step 402 each of the candidate APs is added tothe Available_Sensors bucket.

At step 404, the system chooses the first candidate AP (here AP1) andselects the allowed frequencies. This process is described in moredetail with regard to FIG. 5, and will not be repeated here. Assume forpurposes of this example that each of APIs neighbors meet the frequencyand power criteria described with regard to FIG. 5. At step 406, and asdiscussed in more detail with regard to FIG. 6, the system evaluates theneighbor nodes for AP1. As illustrated in FIG. 3, AP1 has fourneighbors: AP2, AP3, AP4, and AP5. Because AP1 is the first candidate APbeing evaluated, the Covered_Neighbors bucket is initially empty, and soeach of these neighbors are added to the Covered_Neighbors bucket (noneare added to the Supplemental_List bucket).

FIG. 8B illustrates evaluation of the next candidate in the example,AP2. AP2 has four neighbors: AP1, AP4, AP5, and AP6. Assume again thateach of these neighbors meets the frequency and power criteria describedwith regard to FIG. 5. The first neighbor, AP1, does not yet appear inthe Covered_Neighbors bucket, and so it is added to Covered_Neighbors.The next two neighbors, AP4 and AP5, already appear inCovered_Neighbors, so they are added to the Supplemental List. The finalneighbor, AP6, does not appear in Covered_Neighbors, so it is added toCovered_Neighbors.

FIG. 8C illustrates evaluation of the final candidate in the example,AP3. AP3 has two neighbors: AP1 and AP5. Assume again that each of theseneighbors meets the frequency and power criteria described with regardto FIG. 5. Each of these neighbors already appears in theCovered_Neighbors bucket, and so AP1 and AP5 are each added to theSupplemental_List.

This is the final candidate AP in the example, so the system moves tostep 410 illustrated in FIG. 4. Steps 410 and 412 are discussed abovewith regard to FIG. 4, and will not be repeated here. FIG. 8Dillustrates step 414: optimized pruning, discussed in more detail withregard to FIG. 7.

At steps 702 and 704, illustrated in FIG. 7, the system evaluates thesensor reachability of the candidates. Assume for this example that allthree candidate APs have more than minimal sensor reachability. None ofthe sensors are removed in steps 702 and 704, and the system proceeds tostep 706. At step 706, the system removes any sensor appearing only inthe Supplemental_List. Here, AP3 appears only in the Supplemental_Listbecause both of its neighbors are already covered by AP1 and AP2. Thismeans that when AP1 and AP2 are used as sensors, they can generate KPIfor all of AP3's neighbors, and so AP3 is redundant. AP3 is thereforeremoved from the Available_Sensors bucket and is not used as a sensor.AP3 can be left free for client service or other tasks. The system thenundertakes a final evaluation of sensor coverage, as illustrated by step416 of FIG. 4, and the process concludes.

The embodiments described above provide sensor coverage estimation fornetwork service assurance. One objective of this framework is tohighlight a minimum set of sensor APs with the highest reachabilityfactor that could be used to cover multiple nearby nodes, while at thesame time removing unavailing and redundant sensor APs that do notprovide additional insight. For a given deployment, these embodimentscan showcase per sensor, per site, and overall sensor coverage, which isuseful for network administrators to gain insights into different sensorcoverage zones and potential areas where additional sensors can beplaced. Further, network administrators can use data received from thesensors to troubleshoot, and to verify network reliability andefficiency.

Several non-limiting advantages of the disclosed embodiments includeproviding sensor reachability/coverage estimates for network serviceassurance, ensuring only effective sensor APs are chosen, measuring keyperformance indicators across nodes, providing a dynamic list of sensornodes based on the network policy and user requirements, incorporatingphysical RF constraints to make the system portable across differentWLAN vendors, and providing granular insight into per radio sensorcoverage along with network wide sensor coverage. Further, theembodiments herein highlight sites where additional sensor APs would bebeneficial.

In the preceding, reference is made to embodiments presented in thisdisclosure. However, the scope of the present disclosure is not limitedto specific described embodiments. Instead, any combination of thedescribed features and elements, whether related to differentembodiments or not, is contemplated to implement and practicecontemplated embodiments. Furthermore, although embodiments disclosedherein may achieve advantages over other possible solutions or over theprior art, whether or not a particular advantage is achieved by a givenembodiment is not limiting of the scope of the present disclosure. Thus,the preceding aspects, features, embodiments and advantages are merelyillustrative and are not considered elements or limitations of theappended claims except where explicitly recited in a claim(s).

As will be appreciated by one skilled in the art, the embodimentsdisclosed herein may be embodied as a system, method or computer programproduct. Accordingly, aspects may take the form of an entirely hardwareembodiment, an entirely software embodiment (including firmware,resident software, micro-code, etc.) or an embodiment combining softwareand hardware aspects that may all generally be referred to herein as a“circuit,” “module” or “system.” Furthermore, aspects may take the formof a computer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium is any tangible medium that can contain, or store a program foruse by or in connection with an instruction execution system, apparatusor device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent disclosure may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present disclosure are described below with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodimentspresented in this disclosure. It will be understood that each block ofthe flowchart illustrations and/or block diagrams, and combinations ofblocks in the flowchart illustrations and/or block diagrams, can beimplemented by computer program instructions. These computer programinstructions may be provided to a processor of a general purposecomputer, special purpose computer, or other programmable dataprocessing apparatus to produce a machine, such that the instructions,which execute via the processor of the computer or other programmabledata processing apparatus, create means for implementing thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality and operation of possible implementations ofsystems, methods and computer program products according to variousembodiments. In this regard, each block in the flowchart or blockdiagrams may represent a module, segment or portion of code, whichcomprises one or more executable instructions for implementing thespecified logical function(s). It should also be noted that, in somealternative implementations, the functions noted in the block may occurout of the order noted in the figures. For example, two blocks shown insuccession may, in fact, be executed substantially concurrently, or theblocks may sometimes be executed in the reverse order, depending uponthe functionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts, or combinations of special purpose hardware andcomputer instructions.

In view of the foregoing, the scope of the present disclosure isdetermined by the claims that follow.

What is claimed is:
 1. A network controller, comprising: a processor;and a memory containing a program that, when executed on the processor,performs an operation, the operation comprising: estimating a firstnetwork sensor coverage level for a plurality of candidate access points(APs), based on potential use of the plurality of candidate APs asnetwork sensors to measure at least one key performance indicator (KPI);determining a subset of the plurality of candidate APs, based onevaluating the plurality of candidate APs for suitability as networksensors; estimating a second network sensor coverage level for thesubset of the plurality of candidate APs, based on potential use of thesubset of the plurality of candidate APs as network sensors; determiningthat the second network sensor coverage level is within a pre-definedthreshold of the first network sensor coverage level; and provisioning aradio in each AP in the subset of the plurality of candidate APs as anetwork sensor to measure at least one KPI.